home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc614 < prev    next >
Encoding:
Text File  |  1991-04-20  |  11.1 KB  |  233 lines
  1. Network Working Group                                   K. Pogran (MIT-Multics)
  2. Request for Comments: 614                                   N. Neigus (BBN-NET)
  3. NIC #21530                                                             Jan 1974
  4. References: RFC #607, RFC #542
  5.  
  6.  
  7.     Response to RFC 607, "Comments on the File Transfer Protocol"
  8.  
  9.  
  10. Mark Krilanovich and George Gregg have pointed out a number of "sticky"
  11. issues in the current File Transfer Protocol. Although we don't agree
  12. with all of their proposed protocol modifications, we do feel that each
  13. of the points they have raised should be given some thought by everyone
  14. concerned about FTP. Each numbered paragraph in the discussion below is a
  15. comment on the identically-numbered paragraph in RFC 607.
  16.  
  17. 1. Instructions to the Server to be "passive" are defined to apply only
  18. to the next single file transfer operation, after which the Server
  19. reverts to active mode. RFC 607 does, however, point out a drawback in
  20. the present specification, in that there is no way for a user to "change
  21. his mind": once he has told a server to be "passive", he has to initiate
  22. some file transfer operation. The suggested solution is a welcome one. We
  23. suggest that the text of the "successful reply" to the ACTV command
  24. indicate whether the server had previously been in "active" or "passive"
  25. mode, viz:
  26.  
  27. 200 MODE CHANGED TO ACTIVE
  28.  
  29. or
  30.  
  31. 200 MODE IS ALREADY ACTIVE
  32.  
  33. It is important to note that once some servers "listen" on a connection
  34. in response to a PASV command, they no longer can examine the Telnet
  35. control connection for the possible arrival of an ACTV command. User-FTP
  36. programs should precede the ACTV command with a SYNC sequence to ensure
  37. that the server will see the ACTV command.
  38.  
  39. 2. While the length of an FTP command -- either three or four characters
  40. -- might often be irrelevant to a system which interacts over Telnet
  41. connections on a line-at-a-time basis, we can see how a variable command
  42. length might be harder for a character-at-a-time system to handle,
  43. especially for a server implemented in assembly language. Quite a bit is
  44. gained, and nothing seems to be lost, by requiring that FTP commands be
  45. four characters, so we agree with the suggestion in RFC 607.
  46.  
  47. 3. While the FTP document may be somewhat ambiguous in its specification
  48. of the order of the handshaking which takes place following a file
  49. transfer command, such an order does exist as far as is possible for the
  50. two asynchronous processes described in "The FTP Model" (section II. B of
  51. RFC 542) -- the Telnet Control process (Protocol Interpreter) and the
  52. Data Transfer process. The user is required to "listen" on the data
  53. connection before sending the transfer command.  Upon receipt of the
  54. command the server should first check that the status of the file
  55. specified by the argument to the file transfer command is okay, and, if
  56. so, attempt to open the data connection. If there are file system
  57. problems, no attempt should be made to open the connection. In this way,
  58.  
  59.                                     -1-
  60.  
  61. the primary response to the command gives an accurate picture of the
  62. transfer status -- i. e., connection opened and transfer started (250),
  63. or connection not opened because of file problems (450, 451, 455, 457) or
  64. connection problems (454). The secondary reply follows the conclusion of
  65. the transfer, and describes its success or failure.
  66.  
  67. If a particular FTP implementation cannot monitor the data connection and
  68. the Telnet control connection simultaneously, then it must establish a
  69. timeout waiting for the data connection RFC. In addition, a minimum
  70. interval should be specified for which all servers must wait before
  71. deciding that the data connection cannot be opened. We suggest that this
  72. interval be no shorter than fifteen seconds.
  73.  
  74. 4. The protocol states that servers should return "success", replies to
  75. commands such as ACCT and ALLO which were irrelevant to them. We
  76. recommend that the protocol say "must" rather than "should".
  77.  
  78. 5. Specification of maximum lengths for lines, pathnames, etc.  is a fine
  79. idea, as is the suggestion of a Server poll.  Typical values for the
  80. present Multics implementation (provided by Ken Pogran) are as follows:
  81.  
  82. Telnet lines: 256
  83. User names: 32
  84. Passwords: 8
  85. Account Numbers: (na)
  86. Pathnames: 168 (yes, 168)
  87.  
  88. 6. We strongly disagree with Mark on this point. The algorithm a user-FTP
  89. should use goes something like this:
  90.  
  91. a. Examine the first four characters of the reply.  
  92. b. If the fourth character is a space, the reply is not a multi-line reply.  
  93. c. If the fourth character is a hyphen, the reply is a multi-line reply,
  94. and the text portion of this line and succeeding lines should be reported
  95. to the user if this is desired.
  96. d. On each succeeding line, if the first four characters are not the
  97. three digits of the original reply code followed by a space, the line is
  98. entirely a text line and should either be reported to the user or
  99. discarded.
  100. e. If the first four characters on the line are the three digits of the
  101. reply code followed by space, this line is the last line of the reply.
  102.  
  103. This algorithm seems simple enough, if nesting of replies is not required
  104. (see comments on paragraph 7, below). This sort of continuation-line
  105. convention provides a number of benefits to the person coding a server.
  106. Consider the problem of providing a directory listing, in response to a
  107. STAT command whose argument is the pathname of a directory. If the FTP
  108. Telnet control connection is treated as a pseudo-typewriter (as most
  109. ordinary Telnet connections are), the writer of an FTP Server may be able
  110. to "borrow" the code from the system command which provides directory
  111. status (listing) information, as follows (in a pseudo-PL/l syntax):
  112.  
  113. call write_out_line ("151- Directory listing follows") ;
  114. call list_directory_contents (directory_pathname);
  115. call write_out_line ("151 Directory listing complete");
  116.  
  117.                                     -2-
  118.  
  119. The same can be done for the file status reply (code 150).  Otherwise, a
  120. program must be written which performs the function of the
  121. directory-listing command, but uses a special output format. If the
  122. implementor of an FTP Server wants to be "nice" and list file attributes,
  123. as well as file names, in the directory listing (as many
  124. directory-listing commands do), this could be a fairly big job. If
  125. already-written software can be borrowed and incorporated into the FTP
  126. Server, the implementor of the FTP Server can put more of his effort into
  127. doing a better job of building the "guts" of the FTP Server.
  128.  
  129. 7. It is not obvious why multi-line replies are allowed to be nested to
  130. an arbitrary depth. Only truly spontaneous replies may nest inside other
  131. replies -- and it is easy to convince yourself that they will only nest
  132. to depth one. It was envisioned that some messages from "the system"
  133. might not allow the "exterior" multi-line message to finish; the scenario
  134. might go something like this:.
  135.  
  136. 151- Directory listing follows:
  137. a1pha.p11
  138. alpha
  139. rfc.runoff
  140. mailbox
  141. 010- From Operator:
  142. 010 Emergency shutdown in 5 mins. due to hardware probs.
  143. beta.fortran
  144. foo.lisp
  145. 151 Directory listing complete.
  146. It has been pointed out to us that:
  147.  
  148. a. Messages from "the system" in general cannot be guaranteed to come at
  149. the beginning of a line.
  150.  
  151. b. It may be difficult to modify "the system" to preface such messages
  152. with an appropriate FTP reply code.
  153.  
  154. Therefore, we propose that, since user-FTP implementations must handle
  155. multi-line replies, system messages "splattered" into the middle of
  156. replies need not be escorted by FTP reply codes. The user-FTP thus need
  157. not detect and handle "nested" FTP replies.
  158.  
  159. 8. RFC 607 proposes that any data between the last end-of-record marker
  160. of a file and the end-of-file marker be discarded. We agree. The sender
  161. of the data has clearly violated the protocol, and the receiver cannot
  162. divine the sender's original intent.
  163.  
  164. 9-11. The suggestion that reply codes beginning with the digit "2" be
  165. taken as successful, and all others be taken as failures, severely
  166. restricts use of the available "reply code space". We agree that the
  167. present scheme is disorganized and requires far too much "intelligence"
  168. on the part of a user-ftp automaton. With the present scheme, unless the
  169. automaton's reply-interpretation is table-driven, it is extremely likely
  170. to make a mistake. We feel that the whole reply code strategy should be
  171. redesigned; some of the ideas proposed in RFC 607 could fit in with such
  172. a redesign, but we do not think that Mark's suggestion is the way to go.
  173.  
  174.                                       -3-
  175.  
  176. 12. 000 and 020 are used by the Server to indicate that it has heard and
  177. answered the ICP to socket 3, but cannot accept file transfer commands
  178. yet. 020 was intended to indicate how much of a time delay could be
  179. expected, while 000 was ambiguous on this point. We suggest that the two
  180. be merged to mean "I am here; please wait a specified or unspecified
  181. amount of time"; then, 300 would clearly mean "I am ready; you may now
  182. send me commands".
  183.  
  184. 13. There is no typographical error here. A TENEX representative
  185. suggested that, rather than give a "fail" reply to a particular request
  186. because the user is not logged in, a server might ask for his account
  187. number (or ask him to log in) and then proceed with the previous request,
  188. which has been held in abeyance. While this may be convenient for a
  189. server, it is not necessary, and certainly ambiguous to hold a command in
  190. abeyance while obtaining an account number.  Since any server may spring
  191. this on a user, all user-FTP implementations must be able to cope with
  192. this twist, which adds a good deal of required complication to the
  193. "minimal" user-FTP implementation. We propose that the 331 reply be
  194. eliminated, and that the server forget the requested operation and return
  195. a 4XX reply if an account is needed.
  196.  
  197. Jon Postel has remarked that "mail text should follow the same limit as
  198. commands and long 'lines' of mail text have been trouble for some FTP
  199. Servers." We agree. In fact, mail transmitted over the FTP Telnet control
  200. connection has other problems, too: Since FTP is (nominally, at least)
  201. supposed to be usable from TIPs, Multics implemented its standard
  202. character erase and line kill conventions on the control connection for
  203. the convenience of TIP users (it was actually easier to have those
  204. conventions in effect than to turn them off!). Of course, no erase/kill
  205. processing was done on the data connection. The intent of the MAIL
  206. request was to allow users at terminals to access an FTP Server directly
  207. and transmit mail; it was presumed that mail-sending automata which
  208. gathered the mail to be sent into a file would use the MLFL command and
  209. transmit the mail over the data connection.  Presumably, long lines would
  210. not be a problem, and, of course, no erase/kill conventions would be in
  211. effect. Well, at least one major system (TENEX) has a mail-sending
  212. automaton which transmits mail over the Telnet control connection using
  213. the MAIL command - even though it has previously gathered the mail into a
  214. file!  Line-length considerations could be a severe problem here, and the
  215. fact that the Multics line-kill character is the at-sign (@) caused grief
  216. in reading mail from TENEX users who included their "return address" in
  217. TENEX's SNDMSG syntax, as USERNAME@HOST. We propose that mail-sending
  218. automata be required to use MLFL, rather than MAIL.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.                                   -4-